前言

今天不講系統，要講兩個我實際在開發中用過兩個很實用的 Claude 小技巧

1. 可以讓不同 session 互相對話，幫你做更多決策
2. 如何解決 Token 不夠用的問題

昨天說到

昨天把權限和認證補上，今天換個方向：兩個工具本身的用法。

一、session 之間可以直接對話

大部分有在使用 Claude Code 的人，應該都習慣同時開好幾個 session 分工，但我以前一直把它當成「同時開幾個 Claude，各做各的」。直到這次才發現：Claude Code 的 session 之間，其實可以互相看見、傳訊息，甚至可以拿來做派工。

Claude Code 可以透過 ListAgents 列出目前其他 session：

This session is notes-36 [7983d7]

Peer sessions (4):
  spec-74 [8b4702]  ·  interactive  ·  idle  ·  started 32m ago
  impl-d4 [9038ca]  ·  interactive  ·  idle  ·  started 32m ago
  ...

這些 session 名稱其實就像地址。

例如：

SendMessage({to: "impl-d4", message: "..."})

就可以把訊息送到另一個 session。

實際收到的回覆大概會是：

"指派 Issue #3 版本歷程檢視" → impl-d4 (another Claude session on this machine;
queued there — a [Cross-session delivery notice] follows if that session holds it
(different permission mode: its user must approve first) or refuses it)

Subscribed — you will get one notice here when "impl-d4" is next idle (or exits)

三件事值得注意：

• 訊息是排進對方的佇列，不是插話。 對方正在做事的時候不會被打斷。
• 權限不能被跨 session 繞過。 如果兩個 session 的權限模式不同，對方仍然需要由自己的使用者核可。
• 完成通知也是非同步的。你送出訊息後會被訂閱，對方下次進入 idle 或退出時，你這邊會收到一次通知。

所以它比較不像「兩個 AI 即時聊天」，更接近的是：

派工 → 各自處理 → 完工通知

這其實比「兩個 AI 對話」更貼近實際的 SA／PG 協作方式。

SA 不會站在 PG 旁邊，看著他一行一行寫 Code；比較常見的是把工作交出去，等對方完成，再回頭確認結果。

真正的價值是 context 隔離，不是角色扮演

如果只是想讓同一個 Claude 同時扮演 SA 和 PG，其實沒有太大意義，因為它的 Context 並沒有因此消失，它還是知道剛才那份 Code 是怎麼寫的。

所以我這次刻意把工作拆成兩個 session：

這個差異很重要，當 SA 問：「規格裡這條需求有沒有真的被實作？」，PG 不能只靠另一個角色剛才留下的記憶回答，它必須真的去看程式碼、看測試，然後回答。

換句話說，Session 隔離不是為了讓 Claude「演得更像 SA 或 PG」。

而是刻意讓兩個角色擁有不同的 Context，再透過共同的規格與契約交換資訊。

實際跑一輪

派工的內容是「版本歷程檢視」這個工作單元。PG 那邊只有 repo 和 specs/，沒有任何前面二十天的來龍去脈。

一、它遵守了一條它沒參與討論過的規則。

交回來的第一筆是：

test: 版本歷程檢視的五條驗收條件（RED）

前面訂過「每個工作單元至少兩筆 commit，test: 在前、feat: 在後」，那條寫在 CLAUDE.md 裡。這個 session 沒有經歷過訂規則的那段對話——它是讀到的，然後照做了，連 commit 訊息的格式都跟前幾輪一致。

規範寫下來才會發生，這件事終於有了一個乾淨的證據：它對一個沒有上下文的 session 也有效。

二、它改掉了一段我放著沒改的文件，還留了一句話說明為什麼該改。

CLAUDE.md 開頭有一段「這個 repo 現在是什麼」。它補完現況之後，加了這個：

> This section is the first thing every session reads. **When a work unit changes
> what the system can do, change this paragraph in the same commit** — it was left
> saying "a skeleton, deliberately" through four delivered work units.

那「四個工作單元」是我。 我連續交付了四輪，從來沒更新過那段——它一直寫著「刻意只有骨架」，而系統早就能登入、能寫記錄、能送出、能簽核了。

我沒看見它過期，因為我不需要看它。我知道系統現在是什麼樣子。而一個剛進來的 session 只能相信文件，所以它一進門就撞到不對。

持有上下文的人，看不見文件過期。 這句話我在前面寫過類似的意思，但這是第一次被別人示範給我看。

三、它發現一個錯誤碼的語意被我改掉了，而我沒注意到。

契約裡多了這一段：

> **`USER_NOT_FOUND` 換了意思。** 假身分時代它是 401「你宣稱的身分查無此人」；
> 現在身分來自簽章，那條路徑改回 `INVALID_TOKEN`。這個碼只剩一個用途：
> 建立會議時參與者清單裡有查不到的 id——所以它是 404。

換認證那輪，我把身分的來源整個換掉，沒想到有個既有的錯誤碼會因此改變意思。從裡面看它只是「某條路徑不再用這個碼」；從外面看它是「同一個碼，兩個時期代表不同的事」。

三件事的共同點是：它們都不是「PG 比較厲害」，是「PG 只能從文件看」。 而那個限制，剛好就是它的價值。

二、Claude 配額視窗錨定排程

Claude 的用量配額是滾動視窗：從你當天第一次送出訊息那一刻起算 5 小時。

這代表視窗起點是「浮動」的——你今天 09:12 開工，視窗就是 09:12～14:12；明天 10:40 才開第一句，視窗就整個往後挪。結果是配額用完的時間點每天都不一樣，很難安排。

錨定：固定時間先送一則訊息

做法很簡單——在固定的時間點，讓一個排程送一則 hi 給 Claude。視窗的起點就被釘在那裡了。

一天釘三次，工作時間就被切成三段可預測的區間。

⚠️ 兩個排程機制不要搞混

這是我覺得最容易踩的地方。Claude Code 有兩種「排程」，名字都像，但只有一種做得到這件事：

要錨定配額，session 內的那種完全不行——早上六點半你不會開著 Claude Code。

實際設定

用 /schedule 建三支 routine，內容就是一則 hi，模型挑便宜的就好。

在 Claude Code 裡把下面整段（含 /schedule 那行）貼進去送出，Claude 會帶你走完建立流程：

/schedule

幫我建立 3 個雲端 routine，用途是「配額視窗錨定」：每天固定時間自動開一個雲端
session 送一句 hi，把 5 小時的用量視窗釘在固定起點。

共同設定：
- 環境：Default
- 模型：claude-sonnet-5
- prompt 內容就一個字：hi
- 不要掛任何 git repo（不需要 repo source，也不需要 GitHub App）
- 不要掛任何 MCP connector
- enabled: true

三個排程（我的時區是 Asia/Taipei，請幫我換算成 UTC cron）：
1. 名稱「Quota Reset - 06:30」→ 台北時間 週一至週五 早上 06:30
2. 名稱「Quota Reset - 11:30」→ 台北時間 週一至週五 中午 11:30
3. 名稱「Quota Reset - 16:30」→ 台北時間 週一至週五 下午 16:30

注意第 1 條：台北 06:30 = 前一天 22:30 UTC，所以它的 cron 星期欄位是 0-4
（週日～週四），不是 1-5。建立前請把三條的 UTC cron 列出來給我確認。

小結

• 同一個 session 同時當 SA 和 PG，有結構性的問題
• 分兩個 session 的價值是 context 隔離，不是角色扮演
• 實際跑一輪，PG 抓到的三件事全是**「只能從文件看」才看得到的**
• 配額是跟著你當天第一則訊息的滾動五小時視窗。用排程在固定時間送一則 hi，就把起點釘住了。

明天：回到系統實作。